這篇不談技術細節，來聊聊上線之後，回頭看這一路的使用心得。

這次的sideproject紀錄是寫給跟我一樣的新手。走到第 29 天，想記錄這個專案真的被用起來是什麼感覺、哪些事出乎我的意料、哪些地方 AI 幫了大忙，又有哪些事其實該自己握著方向盤。

先快速回顧：它現在長怎樣

使用者填基本資料和飲食習慣 → 程式用固定公式算出熱量與營養目標 → AI 讀懂使用者的生活型態 → 從真實的外食資料庫挑選食物 → 程式算好份數 → 呈現一份菜單。資料庫目前收了約 1900 筆外食資料，以連鎖速食和便利商店為主。

心得一：真的拿給人用，才發現自己沒想到的事

電腦上正常，不代表手機上正常。 我一直在電腦上開發和測試，用手機打開正式網址才發現三大營養素的卡片排版跑掉。原因是我寫死了三欄，沒有針對手機做響應式。這種問題，自己盯著電腦螢幕永遠看不到。

會有人亂填。 我自己測試時故意輸入 175 公分、700 公斤，算出來的基礎代謝率超過一萬大卡，離譜到不可能。這讓我補上體重校正的邏輯。使用者不一定會乖乖填，程式要先想過極端情況。

心得二：數字合不合理，還是要靠專業判斷

有一次我用一組正常的輸入（26 歲、165 公分、62 公斤）測試，發現「油脂與堅果種子類」只算出 0.5 份，連基本的烹調用油都不夠，明顯不合理。原因是前面幾類吃掉了大部分脂肪額度，剩下的就逼近零。最後我把這一類的份數下限調高。

這件事讓我更確定當初那條設計鐵律：營養數字由程式用固定公式算，AI 只負責理解語言和挑選食物。 不是 AI 不夠聰明，而是營養數字需要可預測、可驗證，還要能被專業判斷覆核。用起來越久，越覺得這個分工是對的。

AI 也會偷懶。 有一個欄位原本要 AI 描述「哪一餐外食、哪一餐在家煮」，結果它只是把我已經給它的外食頻率原封不動抄回來，因為那是最省力的路徑。教訓是：欄位只定義型別不夠，要在 prompt 裡講清楚這個欄位存在的目的，以及它不能做什麼。

心得三：最頭痛的事，是 AI 產出的菜單很難控制

這是整個專案裡讓我最頭痛的部分。營養數字是程式算的，不會亂；難的是「AI 從資料庫裡挑出來的菜單」，常常出現我沒預期到的內容。

實際遇過的狀況（都是真實測試時發現的）：

• 早餐被配上韓式蒜味炸雞（附餐候選池不分餐次）。
• 晚餐、宵夜出現含咖啡因的飲料（咖啡因關鍵字漏掉鐵觀音、四季春、茉莉…）。
• 附餐被推薦「無籽冰梅肉」（一種酸酸甜甜的話梅零食，因為點心零食和配菜混在同一個候選池）。
• 整份菜單看不到蔬菜（蔬果品項混在龐大的附餐池裡，隨機抽樣幾乎抽不到）。
• 蔬菜目標 3 份卻給到 6.5 份（AI 同一餐選了兩份生菜沙拉）。
• 宵夜被建議吃 4 份油脂堅果（緩衝餐機制只管數字加總對不對，不管量合不合理）。

意外的發現：多半不是 AI 亂編。 每次我都先查證，這些食物幾乎都是資料庫裡真實存在的品項，AI 並沒有編造。問題出在：候選池怎麼分類、規則有沒有寫進程式、prompt 有沒有講「上限」。也就是說，AI 被放進了一個沒有被好好設計的選擇空間。

我怎麼修的（前後修了七輪）： 多數修法落在「資料和程式邏輯」，而不是改 prompt：

• 限制候選池：早餐排除附餐、點心零食不進附餐池、蔬果獨立成一個候選池。
• 關鍵字表補漏，並加上合理性門檻。
• 事後驗證：份數對不齊或超支就重打一次，緩衝餐把餘額補回去。
• 少數才是 prompt：每餐蔬果最多選 1 個、建議文字不寫營養術語、不要抄現成值。

這個過程的感覺是：修好一個，又冒出一個。每次都是出了錯才回頭跟 AI 一起調，像在補洞。

我的臆測（還沒驗證）： 回頭看，我覺得比起「出一次錯、請 AI 調一次」，也許更值得在一開始就把兩件事設計得更細：

1. 資料庫：食物進來時就標好欄位（是不是含咖啡因、是不是油炸、是配菜還是點心），而不是執行時靠名稱關鍵字去猜。關鍵字比對我至少踩到同一種坑五次（蕃茄、鮪魚、烏龍茶…），像是補不完的長尾。
2. prompt：每個欄位不只寫型別，還要寫目的、禁止事項和數量上限。

但這只是我的猜測，我並不確定真的會更好，也有可能換成另一種新的意外。我想把它留成之後可以實驗的題目。目前比較有把握的一句話（限定在這個專案）： 「請 AI 注意」不如「讓程式決定 AI 能選什麼」。規則越是從 prompt 搬到資料和程式裡，結果就越穩。

心得四：踩雷是最有價值的部分

這個專案花最多時間的，不是寫功能，而是排查那些教科書不會寫的小事：

• Lambda 的 Timeout 預設只有 3 秒，等 AI 回應根本不夠，直接逾時。
• 明明說只回 JSON，Haiku 還是會用 code fence 包起來，導致解析失敗。
• IAM 權限都給了還是被拒絕，原因是帳號還沒真正完成模型的訂閱。
• 在 Windows 的終端機用 curl 直接帶中文，編碼會被污染。
• 編輯器某次把兩個檔案還原回舊版，掉了三個我之前定案的專業修正，是靠測試檔比對才抓出來。

最後這一件讓我對「寫測試」有了實感：測試不只是證明程式對，更是程式被悄悄改壞時的警報器。

心得五：跟 AI 一起開發是什麼感覺

我想誠實講，因為這跟「AI 幫我做完了」的印象很不一樣。

• 速度真的快很多。 環境建置、樣板程式、查錯方向，這些 AI 幫了大忙，我不用卡在一個小設定上好幾天。
• 專業判斷我自己握著。 六大類份數怎麼換算、體重怎麼校正、prompt 裡哪些規則要寫，這些是我依營養師的實務經驗定案的，AI 負責提選項、把想法變成程式。
• 也有失衡的時候。 部署那一段，AI 一口氣做完才回報結果，我反而覺得「這跟我沒關係」，事後很難講出自己理解了什麼。後來改成：重要的決策點，動手前先講清楚再做。

我現在的看法是：用 AI 不是把任務丟出去，而是知道哪裡可以放手加速、哪裡該自己握住方向盤。

給跟我一樣的新手，三個小建議

1. 先打通整條路，再回頭優化。 這個專案的第一個目標只是「公開網址可以操作」，先有一條能走完的路，後面的優化才有方向。
2. 用真實資料和極端輸入測試。 資料庫接上之後，來回測了好幾輪，每一輪都挖出新的問題，這些在理想情境下是看不到的。
3. 上線之前，先問自己最壞情況。 把網址分享出去前，先想「如果有人狂點，我要付多少錢」，再決定要設哪些防線（見 Day28）。

小結

上線不是終點，而是開始被真實使用檢驗。這個專案讓我體會到，跨領域的價值不是「懂一點技術、懂一點營養」，而是能判斷什麼事該交給 AI、什麼事該交給程式、什麼事該留給自己的專業。

下一篇 Day30 是最後一篇，整理這個專案接下來如果要進化的話，還可以怎麼發展。
(突然覺得好感動終於撐到最後了嗚嗚~)